Google Workspaceのモバイルデバイス管理（MDM）では、組織部門（OU）を活用してデバイスポリシーをきめ細かく制御できます。OUの階層構造とポリシー継承の仕組みを理解し、適切に設計することで、部門や役職に応じたセキュリティと利便性の両立が可能です。
この記事を読んだほうが良い人
- Google Workspaceを100名規模で管理している情シス担当者
- Google Workspace MDMを既に有効化しているが、部門ごとのポリシー適用に課題を感じている方
- 組織部門（OU）設計とデバイスポリシーの関係性を深く理解し、実践に活かしたい方
- BYOD（Bring Your Own Device）と会社支給デバイス（COPE: Corporate-Owned, Personally-Enabled devices）が混在する環境でデバイス管理を最適化したい方
Google Workspace MDMのOUとポリシー継承の基本
Google Workspaceにおける組織部門（OU: Organizational Unit）は、ユーザーやデバイスを論理的にグループ化するための機能です。MDM（Mobile Device Management）のデバイスポリシーは、このOUの構造に基づいて適用されます。
組織部門（OU）とは？
OUは、ユーザーアカウントやデバイスを管理コンソール内で階層的に分類する仕組みです。例えば、「全社」の下に「営業部」「開発部」「管理部」といった部門OUを作成し、さらにその下に「営業1課」「営業2課」といった課のOUを設けることができます。
OUの主な目的は以下の通りです。 - ポリシー適用: 特定のOUに属するユーザーやデバイスにのみ、特定のポリシーや設定を適用する。 - 管理権限の委任: OU単位で管理者に特定の権限を付与し、管理業務を分散する。
ポリシー継承の仕組み
Google Workspaceのデバイスポリシーは、OUの階層構造に従って継承されます。これは、親OUで設定されたポリシーが、特に設定が上書きされていない限り、その子OUにも自動的に適用されるという特性です。
基本的なポリシー継承のルールは以下の通りです。 1. デフォルトの継承: 子OUは、親OUで設定されたすべてのデバイスポリシーを継承します。 2. 上書きの優先: 子OUで個別のポリシーを設定した場合、その設定が親OUからの継承設定よりも優先されます。これを「上書き」と呼びます。 3. 最下層の適用: 最終的にデバイスに適用されるポリシーは、そのデバイスが属するOUのポリシー、または上書きされていない場合は親OUから継承されたポリシーです。
この仕組みにより、管理者は全社共通のポリシーを最上位OUで設定しつつ、特定の部門やグループにのみ異なるポリシーを適用するといった柔軟な運用が可能になります。
OU階層とポリシー継承のイメージ図（概念）
[最上位OU: 全社]
└─ [OU: 営業部] --- (全社ポリシーを継承)
├─ [OU: 営業1課] --- (営業部ポリシーを継承)
└─ [OU: 営業2課] --- (営業部ポリシーを継承)
└─ [OU: 開発部] --- (全社ポリシーを継承、一部上書き)
├─ [OU: 開発1チーム] --- (開発部ポリシーを継承)
└─ [OU: 開発2チーム] --- (開発部ポリシーを継承)
この図のように、上位のOUで設定したポリシーは下位のOUに引き継がれます。下位のOUで特別な設定が必要な場合のみ、そのOUでポリシーを上書きします。
ポリシー継承を「上書き」する判断軸
Google Workspace MDMのポリシー設計において、最も重要な判断の一つが「親OUのポリシーをそのまま継承するか、それとも子OUで上書きするか」です。この判断を誤ると、セキュリティリスクや運用負荷の増大につながります。
継承をそのまま利用するケース
全社として統一したいセキュリティ基準や、全てのユーザーに適用すべき基本設定は、最上位のOUで設定し、下位のOUに継承させるのが効率的です。
継承利用の具体例: - パスワード要件: 全員に最低8文字以上の複雑なパスワードを義務付ける。 - 画面ロック時間: 一定時間操作がない場合に自動で画面ロックをかける。 - 紛失時のデータ消去: デバイス紛失時にリモートでデータをワイプする機能の有効化。 - 不正なアプリのブロック: 業務に不要な特定のアプリを全社的に禁止する。 - OSアップデートの強制: セキュリティパッチ適用のため、最新OSへのアップデートを強制する。
これらの設定は、セキュリティの根幹に関わるため、特定の部門だけ例外を設けるのは避けるべきです。
継承を上書きして個別に設定するケース
特定の部門や役職に特有の業務要件やリスクがある場合、親OUのポリシーを上書きして個別の設定を適用します。
上書き設定の具体例: - BYOD（Bring Your Own Device）の許可/不許可: * 営業部門などBYODを許可するOUでは、会社支給デバイスとは異なるポリシー（例: アプリケーションのインストール制限を緩和、会社データのみのワイプを許可）を適用する。 * 一方、機密情報を扱う開発部門ではBYODを禁止し、会社支給デバイスのみを許可するポリシーを上書き設定する。 - カメラの使用制限: * 工場や研究施設など、情報漏洩リスクの高い場所でのカメラ利用を禁止するため、特定のOU（例: 「製造部」「研究開発部」）ではカメラ機能を無効化する。 * 広報部など、カメラ使用が必須な部門では、制限を緩和する。 - 社内Wi-Fiの自動接続設定: * 特定の拠点に所属する社員のOUで、その拠点の社内Wi-Fiプロファイルを自動設定する。 - 外部ストレージの利用制限: * 開発部門など、情報持ち出しリスクが高いOUでは、USBストレージなどの外部ストレージ利用を厳しく制限する。
上書きは、必要最小限に留めることが重要です。無闇に上書きを増やすと、ポリシーの全体像が把握しづらくなり、管理が複雑化します。
シナリオ別：部門・役職に応じたデバイスポリシー設計例
具体的なシナリオを通じて、OU設計とポリシー適用例を見ていきましょう。
営業部門（BYOD許可）と開発部門（COPE必須）が混在するケース
多くの企業で直面する、BYODと会社支給デバイスのポリシーを分ける必要があるシナリオです。
OU構造の提案:
[最上位OU: 全社]
└─ [OU: 営業部] (BYOD許可)
├─ [OU: 営業部 - BYOD] (BYODデバイス用ポリシー適用)
└─ [OU: 営業部 - 会社支給] (会社支給デバイス用ポリシー適用)
└─ [OU: 開発部] (COPE必須)
└─ [OU: 開発部 - 会社支給] (COPEデバイス用ポリシー適用)
この構造では、まず「営業部」と「開発部」で大まかな方針を分けます。さらに営業部内ではBYODデバイスと会社支給デバイスのOUを分け、それぞれに異なるポリシーを適用します。
具体的なポリシー設定例: - 全社OU: * パスワード要件（最低8文字、複雑性必須） * 画面ロック時間（15分） * 紛失時のデバイスワイプ（アカウントデータのみ） - 営業部OU（継承）: * 特に上書きせず、全社OUのポリシーを継承。 - 営業部 - BYOD OU: * 上書き: アプリケーションインストールの制限を緩和（Google Playストアからのインストールを許可）。 * 上書き: デバイスワイプは「アカウントデータのみ」に限定し、個人データは保護。 * 上書き: 特定の業務アプリ（SFAなど）のインストールを必須化。 - 営業部 - 会社支給 OU: * 全社OUのポリシーを継承。BYODのような緩和は不要。 - 開発部OU: * 上書き: BYODを禁止するポリシーを適用（未登録デバイスからのアクセスをブロック）。 * 上書き: カメラ機能の無効化。 * 上書き: 外部ストレージの利用を禁止。 * 上書き: デバイスワイプは「デバイス全体のデータ」を対象とする。
役員層と一般社員でセキュリティレベルを変えるケース
役員層は機密情報にアクセスする機会が多く、高いセキュリティレベルが求められる場合があります。
OU構造の提案:
[最上位OU: 全社]
├─ [OU: 役員室] (高セキュリティポリシー適用)
└─ [OU: 一般社員] (標準セキュリティポリシー適用)
├─ [OU: 営業部]
└─ [OU: 開発部]
役員専用のOUを設け、一般社員とは異なるセキュリティポリシーを適用します。
具体的なポリシー設定例: - 全社OU: * パスワード要件（最低8文字、複雑性必須） * 画面ロック時間（15分） - 役員室OU: * 上書き: パスワード要件をさらに強化（例: 最低12文字、定期的な変更を強制）。 * 上書き: 画面ロック時間を短縮（例: 5分）。 * 上書き: 特定の機密情報アプリへのアクセスには、より厳格な認証（例: Context-Aware Accessとの連携で特定IPアドレスからのアクセスのみ許可）を求める。 * 上書き: デバイスの紛失/盗難時のワイプは、即時かつデバイス全体のデータ消去を強制。 - 一般社員OU: * 全社OUのポリシーを継承。
よくある失敗パターンと対処法
OU設計とポリシー継承は強力な機能ですが、設計を誤ると予期せぬ問題を引き起こすことがあります。
失敗1: OU設計が複雑になりすぎる
問題点: 細かすぎるOU設計は、ポリシー管理を煩雑にし、どのOUにどのポリシーが適用されているのか把握しづらくします。結果として、ポリシーの見落としや矛盾が発生しやすくなります。
対処法: - シンプルさを追求: まずは大まかな部門分けから始め、本当にポリシーを分ける必要がある場合にのみ、OUを細分化します。 - ポリシーの共通化: できる限り共通のポリシーで運用できる部分は継承を活用し、上書きは最小限に留めます。 - 命名規則の統一: OU名に役割やポリシーの特性を示す情報を加えるなど、一貫した命名規則を設けます（例: 「営業部_BYOD」「開発部_COPE」）。
失敗2: ポリシーの優先順位を誤解する
問題点: 親子OU間でポリシーが上書きされる際の優先順位を誤解し、意図しないポリシーが適用されてしまうことがあります。特に複数のポリシーが絡む場合、複雑になりがちです。
対処法: - 継承の原則を理解: 「子OUの設定が常に親OUの設定を上書きする」という基本原則を徹底的に理解します。 - テストOUの活用: 本番環境に適用する前に、テスト用のOUとユーザーを作成し、期待通りのポリシーが適用されるか検証します。 - ドキュメント化: 各OUに適用される主要なポリシーと、上書き設定の内容をドキュメント化し、チーム内で共有します。
失敗3: テストを怠る
問題点: 新しいOUやポリシーを設定した際に、実際のデバイスで動作確認を怠ると、ユーザーの業務に支障をきたしたり、セキュリティホールを生んだりする可能性があります。
対処法: - 段階的な導入: まずは少数のテストユーザー/デバイスでポリシーを適用し、問題がないことを確認してから、徐々に適用範囲を広げます。 - ユーザーへの影響確認: ポリシー変更がユーザーの利便性や業務フローに与える影響を事前に評価し、必要に応じてユーザーへの周知やトレーニングを実施します。 - フィードバックループ: ポリシー適用後も、ユーザーからのフィードバックを収集し、継続的に改善を行います。
効果的なGoogle Workspace MDM運用への第一歩
Google Workspace MDMのOU設計とポリシー継承は、単なる技術的な設定ではなく、組織のセキュリティと業務効率を両立させるための戦略的な取り組みです。適切なOU構造を設計し、ポリシー継承の原則を理解して活用することで、企業は変化するビジネスニーズに柔軟に対応し、セキュアなモバイル環境を構築できます。
この記事で紹介した設計例や失敗パターンを参考に、自社の組織構造やセキュリティ要件に合わせた最適なMDM運用を目指しましょう。
コーポレートITのご相談はお気軽に
この記事で書いたような業務改善・自動化の設計から実装まで、DRASENASではコーポレートITの現場に寄り添った支援を行っています。 「まず相談だけ」でも大歓迎です。DRASENAS 公式サイトからお気軽にどうぞ。
御社の IT 部門、ここにあります。
「ITのことはあまりわからない」── そのような状態からで、まったく問題ございません。まずはお気軽にご相談ください。